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Updates to the Special-Purpose IP Address Registries 


Abstract 
This memo updates the IANA IPv4 and IPv6 Special-Purpose Address 
Registries to address issues raised by the definition of a "global" 
prefix. It also corrects several errors in registry entries to 
ensure the integrity of the IANA Special-Purpose Address Registries. 
This memo updates RFC 6890. 

Status of This Memo 


This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8190. 
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Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


In order to support new protocols and practices, the IETF 
occasionally reserves an address block for a special purpose. For 
example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to 


represent the local (i.e., "this") network. Likewise, [RFC4291] 
reserves an IPv6 address block (fe80::/10) for link-local unicast 
addresses. 


Several issues have been raised with the documentation of some of the 
special-purpose address blocks in [RFC6890]. Specifically, the 
definition of "global" provided in [RFC6890] was misleading as it 
slightly differed from the generally accepted definition of "global 
scope" (i.e., the ability to forward beyond the boundaries of an 
administrative domain, described as "global unicast" in the IPv6 
addressing architecture [RFC4291]). 


This memo updates the definition of "global" from [RFC6890] for the 
IPv4 and IPv6 Special-Purpose Address Registries, augments the fields 
contained within the registries in order to address the confusion 
raised by the definition of "global", and corrects some errors in 
some of the entries in the Special-Purpose Address Registries. 


This memo updates [RFC6890]. 
2. IANA Considerations 
2.1. Definition of Globally Reachable 


[RFC6890] defined the term "global" without taking into consideration 
the multiple uses of the term. Specifically, IP addresses can be 
global in terms of allocation scope as well as global in terms of 
routing/reachability. To address this ambiguity, the use of the term 
"global" defined in [RFC6890] is replaced with "globally reachable". 
The following definition replaces the definition of "global" in the 
IANA Special-Purpose Address Registries: 


o Globally Reachable - A boolean value indicating whether an IP 
datagram whose destination address is drawn from the allocated 
special-purpose address block is forwardable beyond a specified 
administrative domain. 


The same relationship between the value of "Destination" and the 
values of "Forwardable" and "Global" described in [RFC6890] holds for 
"Globally Reachable". If the value of "Destination" is FALSE, the 
values of "Forwardable" and "Globally Reachable" must also be FALSE. 
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The "Global" columns in the IPv4 Special-Purpose Address Registry 
(https://www.iana.org/assignments/iana-ipv4-special-registry) and the 
IPv6 Special-Purpose Address Registry 
(https://www.iana.org/assignments/iana-ipv6-special-registry) have 
been renamed to "Globally Reachable". 


2.2. Updates to the IPv4 Special-Purpose Address Registry 
o Limited Broadcast prefix (255.255.255.255/32) - The Reserved-by- 
Protocol value has changed from False to True. This change was 
made to align the registry with reservation of the limited 
broadcast address with Section 7 of [RFC919]. 
2.3. Updates to the IPv6é Special-Purpose Address Registry 
The following changes to the "IPv6 Special-—Purpose Address Registry" 
involved the insertion of two new footnotes. These additions 


required that the footnotes be renumbered. 


Oo TEREDO prefix (2001::/32) - The Globally Reachable value has 
changed from False to "N/A [2]". The [2] footnote now states: 


* See Section 5 of [RFC4380] for details. 


o EID Space for LISP (2001:5::/32) - All footnotes have been 
incremented by 1. 


o 6to4 (2002::/16) - All footnotes have been incremented by 1. 
o Unique-Local (fc00::/7) - The Globally Reachable value has changed 
from False to "False [7]". The [7] footnote now states: 


* See [RFC4193] for more details on the routability of Unique- 
Local addresses. The Unique-Local prefix is drawn from the 
IPv6 Global Unicast Address range but is specified as not 
globally routed. 


3. Security Considerations 


This document does not raise any security issues beyond those 
discussed in [RFC6890]. 
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